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Abstract.  SOL  (Secure  Operations  Language)  is  a  synchronous  pro¬ 
gramming  language  for  implementing  reactive  systems.  The  utility  of 
SOL  hinges  upon  the  fact  that  it  is  a  secure  language,  i.e.,  most  pro¬ 
grams  in  SOL  are  amenable  to  fully  automated  static  analysis  techniques, 
such  as  automatic  theorem  proving  using  decision  procedures  or  model 
checking.  Among  the  unique  features  of  SOL  is  the  ability  to  express  a 
wide  class  of  enforceable  safety  and  security  policies  (including  the  tem¬ 
poral  aspects  of  software  component  interfaces)  in  the  language  itself, 
thereby  opening  up  the  possibility  of  eliminating  runaway  computations 
and  malicious  code,  such  as  worms  and  viruses. 


1  Introduction 

SOL  is  a  synchronous  programming  language  which  supports  a  process  for  the 
specification,  design,  automatic  analysis,  and  implementation  of  systems,  more 
specifically  software-intensive  distributed  reactive  computer  systems  as  typified 
by  safety-  and  security-critical  applications  in  the  aerospace,  automotive,  avion¬ 
ics,  biomedical,  military,  nuclear,  railway,  and  telecommunications  industries. 
The  process  underlying  SOL  [4, 13]  helps  users  construct  precise  and  unambigu¬ 
ous  system  descriptions  that  are  easy  to  understand  and  change,  and  that  satisfy 
a  number  of  application  specific  as  well  as  application  independent  properties 
such  as  consistency  and  completeness,  safety,  and  security.  Support  in  SOL  for 
programming-in-the-large  includes  modules,  interfaces,  and  automated  analysis 
using  assumption-guarantee  style  of  reasoning.  It  is  our  belief  that  SOL  provides 
a  cost-effective  solution  to  industrial-strength  problems. 

2  Background 

The  design  of  SOL  was  motivated  by  the  concern  of  building  high  assurance 
systems.  High  assurance  entails  the  presentation  of  compelling  evidence  that  a 
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system  satisfies  critical  properties  including  functional  properties  (i.e..  properties 
of  services  that  the  system  delivers),  and  other  critical  properties  such  as  secu¬ 
rity,  safety,  timeliness  (real-time),  survivability,  and  fault-tolerance.  Since  SOL 
is  a  synchronous  data-flow  language,  programs  in  SOL  are  readily  amenable  to 
automatic  static  analysis  techniques  such  as  automatic  theorem  proving  using 
decision  procedures  [6]  or  model  checking  [5,7].  Admittedly,  such  a  style  im¬ 
poses  some  limitations  on  expressiveness,  which  may  pose  a  problem  in  certain 
circumstances1.  One  should  keep  in  mind  that  it  is  precisely  these  limitations 
that  make  many  interesting  theorems  about  SOL  programs  decidable,  thereby 
opening  up  the  possibility  of  fully  automated  analysis  for  SOL  programs. 

Many  researchers  have  been  working  on  processes  and  tools  for  the  specifica¬ 
tion,  design,  analysis,  and  implementation  of  safety-  and  mission-critical  systems 
[4, 12, 20, 21].  One  such  approach,  known  as  SCR  (Software  Cost  Reduction),  was 
developed  at  the  Naval  Research  Laboratory  (NRL)  to  document  the  require¬ 
ments  of  the  US  Navy’s  A- 7  aircraft  [2, 17].  One  of  the  goals  of  SOL  is  to  be  able 
to  directly  implement  specifications  of  high-quality,  such  as  the  ones  produced 
in  SCR,  in  a  safe  and  efficient  manner.  For  illustrative  SCR  examples,  see  [5, 13, 

14]- 

Researchers  at  NRL  have  provided  a  formal  model  for  the  SCR  notation  [5, 
16] ,  based  upon  which  a  number  of  tools  have  been  developed  [6, 15] .  For  verifying 
programs  in  SOL,  our  intention  is  to  build  upon  one  of  these  tools,  Salsa,  which  is 
an  invariant  checker  for  state  machine  descriptions.  Salsa  establishes  a  formula 
as  an  invariant  (properties  that  are  true  in  all  reachable  states)  by  carrying 
out  an  induction  proof  that  uses  a  tightly  integrated  set  of  decision  procedures 
(currently  a  combination  of  BDD  algorithms  and  a  constraint  solver  for  integer 
linear  arithmetic)  for  discharging  the  verification  conditions.  The  use  of  induction 
and  a  set  of  optimized  heuristics  enable  Salsa  to  combat  the  state  explosion 
problem  that  plagues  current  model  checkers. 

More  recently,  we  have  been  investigating  the  problem  of  building  secure  dis¬ 
tributed  applications  over  the  infrastructure  of  the  Internet  and  the  World  Wide 
Web  [3].  It  is  widely  acknowledged  that  intelligent  software  agents  are  central  to 
the  development  of  the  capabilities  required  to  build  robust,  re-configurable,  and 
survivable  distributed  applications.  However,  agents  technology  carries  with  it 
the  risk  of  security  vulnerabilities  such  as  denial  of  service,  malicious  code,  and 
information  leaks.  The  design  philosophy  of  SOL  is  to  give  developers  the  ability 
to  address  the  security  problems  outlined  above  using  an  easy-to-use  graphi¬ 
cal  interface  supported  by  powerful  analysis  and  synthesis  tools.  Since  agents 
in  SOL  are  verifiable,  composable,  and  modular,  SOL  addresses  the  problem  of 
statically  determining  emergent  behavior  [8]  that  eludes  current  agent  design  and 
implementation  approaches. 


1  A  mitigating  factor  is  the  ability  within  SOL  to  invoke  arbitrary  methods  (i.e., 
functions)  written  in  traditional  programming  languages. 


3  Related  Work 


The  design  of  SOL  was  directly  influenced  by  the  design  of  SAL  (the  SCR  Ab¬ 
stract  Language),  a  specification  language  based  on  the  SCR  Formal  Model  [16]. 
SAL  was  designed  to  serve  as  an  abstract  interface  for  analysis  tools  such  as 
theorem  provers,  model  checkers,  test  case  generators,  and  consistency  check¬ 
ers.  SOL  includes  certain  key  features  of  SAL  including  the  notion  of  events 
and  modularity.  The  tool  Salsa  [6]  uses  SAL  as  the  input  language,  and  can 
perform  automated  analysis  such  as  checking  a  SAL  specification  for  unwanted 
nondeterminism  and  missing  cases,  in  addition  to  the  verification  of  invariants. 
Although  a  theorem  prover,  Salsa  affords  “push-button”  automation,  ease  of  use, 
and  counterexample  generation  that  typify  model  checkers  [5] . 

Another  language  that  influenced  the  design  of  SOL  was  LUSTRE  [11],  a 
language  developed  at  the  IMAG  Institute  in  Grenoble.  SOL  resembles  LUS¬ 
TRE  in  being  a  textual  data-flow  language,  and  in  its  ability  to  include  program 
fragments  (i.e.,  methods  calls )  from  traditional  programming  languages  in  which 
it  is  embedded.  However,  SOL  does  away  with  the  (sometimes  confusing)  no¬ 
tion  of  clocks  of  LUSTRE  without  sacrificing  expressiveness  -  SCR  events  are 
in  essence  “self-timed”  which  obviates  the  need  for  an  explicit  clock.  The  type 
system  of  SOL  is  richer  than  that  of  LUSTRE,  and  includes  enumerated  types, 
real,  and  string  types,  in  addition  to  opaque  types  which  may  denote  arbitrary 
ADTs  (abstract  data  types)  of  the  embedding  language.  It  is  important  to  note 
that  the  analysis  tools  of  SOL  will  provide  support  for  reasoning  in  this  richer 
type  system.  Also,  SOL  borrows  from  POLLUX  [22],  an  extension  of  LUSTRE, 
the  notions  of  tuples  and  arrays.  Features  of  SOL  not  in  LUSTRE  include  mech¬ 
anisms  for  programming-in-the-large  including  modules,  interfaces,  and  mecha¬ 
nisms  for  assumption-guarantee  style  proofs.  Other  features  include  the  ability 
to  directly  specify  a  wide  class  of  enforceable  safety  and  security  policies  (includ¬ 
ing  the  temporal  aspects  of  software  component  interfaces)  using  the  theory  of 
security  automata  in  [1,23]. 


4  Secure  Operations  Language  (SOL) 

4.1  Events 

SOL  borrows  from  SCR  the  notion  of  events  [16].  Informally,  an  SCR  event 
denotes  a  change  of  state,  i.e.,  an  event  is  said  to  occur  when  a  state  variable 
changes  value.  SCR  systems  are  event-driven  and  the  SCR  model  includes  a 
special  notation  for  denoting  them.  The  notation  @T(c)  denotes  the  event  “con¬ 
dition  c  became  true”,  @F(c)  denotes  “condition  c  became  false”  and  @C(x) 
the  event  “the  value  of  expression  x  has  changed” .  These  constructs  are  defined 
formally  below.  In  the  sequel,  PREV(x)  denotes  the  value  of  expression  x  in  the 


previous  state. 


@T(c)  =  -iPREV(c)  A  c 
OF (c)  d=  PREV(c)  A-iC 
OC(c)  d=  PREV(c)  ±  c 

Events  may  be  triggered  predicated  upon  a  condition  by  including  a  “when” 
clause.  Informally,  the  expression  following  the  keyword  when  is  “aged”  (i.e., 
evaluated  in  the  previous  state)  and  the  event  occurs  only  when  this  expression 
has  evaluated  to  true.  Formally,  a  conditioned  event ,  defined  as 

OT(c)  when  d  =f  -.PREV(c)  A  c  A  PREV(d), 

denotes  the  event  “condition  c  became  true  when  condition  d  was  true  in  the 
previous  state” .  Conditioned  events  involving  the  two  other  event  constructs  are 
defined  along  similar  lines. 

In  SOL  we  extend  the  SCR  event  construct  to  include  events  that  are  trig¬ 
gered  by  the  invocation  of  a  method  (i.e.,  a  procedure  or  function  call)  of  the 
embedding  language.  For  example,  the  event  associated  with  the  invocation  of 
method  push(x)  of  a  stack  is  denoted  as  Opush.  This  provides  users  the  ability 
to  implement  security  automata ,  a  special  class  of  Biichi  automata  that  accept 
safety  properties  [1,23]. 

4.2  SOL  Overview 

In  this  section  we  give  an  informal  overview  of  SOL  using  the  stopwatch  of  [11]  as 
a  running  example.  We  have  chosen  this  example  to  illustrate  the  expressiveness, 
readability,  usability,  and  formal  verification  capabilities  of  the  SOL  approach. 
Interested  readers  may  refer  to  [11]  to  compare  this  approach  with  other  syn¬ 
chronous  languages  such  as  Esterel,  Argos,  LUSTRE,  and  SIGNAL.  Informally, 
the  stopwatch  includes  a  display  of  elapsed  time  and  a  button  start-stop  that 
alternately  puts  the  stopwatch  in  “running”  and  “stopped”  states.  Initially  the 
stopwatch  is  stopped.  It  also  receives  a  signal  HS  every  1/100  second,  which  is 
used  to  compute  the  time  spent  in  the  “running”  state.  The  stopwatch  includes 
a  second  button  -  button-2  -  whose  interpretation  depends  on  the  mode  (i.e., 
externally  visible  state)  of  the  stopwatch.  When  the  stopwatch  is  stopped  and 
the  displayed  time  is  running,  the  button  is  interpreted  as  a  RESET  command; 
otherwise  it  corresponds  to  a  LAP  command,  which  freezes  the  display  while  the 
stopwatch  is  still  running. 

In  SOL,  a  system’s  behavior  is  described  in  terms  of  modules.  A  module 
declaration  may  include  one  or  more  attributes.  The  attribute  deterministic 
declares  the  module  as  being  free  of  nondeterminism  (which  will  be  checked  by 
the  SOL  compiler).  Attribute  reactive  declares  that  the  module  will  not  cause  a 
state  change  or  invoke  a  method  unless  its  (visible)  environment  initiates  an  event 
by  changing  state  or  invoking  a  method;  moreover,  the  module’s  response  to  an 
environmental  event  will  be  immediate;  i.e.,  in  the  next  immediate  step.  Each 
module  may  contain  state  variables,  each  one  falling  into  one  of  three  categories: 


Fig.  1.  The  dependency  graph  of  module  stopwatch. 


monitored  variables  which  denote  environmental  variables  observable  to  the 
module;  controlled  variables  which  denote  environment-visible  variables  the 
module  controls;  and  internal  variables  which  are  updated  by  the  module 
but  not  visible  to  the  environment. 

For  the  stopwatch,  we  implement  the  system  as  a  deterministic  and  reactive 
module.  We  identify  three  monitored  variables  -  start_stop,  HS,  and  button_2 
and  a  controlled  variable  display.  The  variable  start_stop,  of  type  boolean,  in¬ 
dicates  the  status  (pressed  or  otherwise)  of  the  button  startstop.  Similarly,  vari¬ 
able  button_2,  also  of  type  boolean  indicates  the  status  of  button-2.  The  boolean 
variable  HS  indicates  the  presence  (or  absence)  of  signal  HS.  We  also  identify 
a  controlled  variable  display  of  type  Time  (i.e.,  integer  in  the  range  0 . . .  oc) 
corresponding  to  the  stopwatch  display.  Finally,  module  stopwatch  includes 
three  internal  variables:  elapsed_time,  also  of  type  Time;  Display  .Status  which 
can  take  on  values  from  the  set  {frozen,  active};  and  Timer_Status  of  type 
{stopped,  running}. 

Each  controlled  and  internal  variable  of  a  module  has  one  and  only  one  defi¬ 
nition  which  determines  when  and  how  the  variable  gets  updated.  All  definitions 
of  a  module  m  implicitly  specify  a  dependency  relation  Dm  such  that  a  variable  a 
depends  on  variable  b  (i.e.,  (a,  b)  £  Dm )  if  and  only  if  b  appears  in  the  definition 
of  a.  Note  that  variable  a  may  depend  on  the  previous  values  of  other  variables 
(including  itself)  which  has  no  effect  on  the  dependency  relation.  A  dependency 
graph  may  be  inferred  from  the  dependency  relation  by  taking  each  variable  in 
the  module  to  be  a  node  and  including  an  edge  from  a  to  b  if  a  depends  on  b2 . 
The  dependency  graph  of  stopwatch  is  shown  in  Figure  1.  Note  that  monitored 
variables  of  the  module  appear  to  the  left  and  controlled  variables  to  the  right. 

It  is  required  that  the  dependency  graph  of  each  module  is  acyclic. 

Intuitively,  the  execution  of  a  SOL  program  proceeds  as  a  sequence  of  steps , 
each  initiated  by  an  event  (known  as  the  triggering  event).  Each  step  of  a  SOL 
module  comprises  a  set  of  variable  updates  and  method  calls  that  are  consistent 
with  the  dependency  relation  Dm  of  that  module.  Computation  of  each  step  of  a 
module  proceeds  as  follows:  the  module  or  its  environment  nondeterministically 
initiates  a  triggering  event;  each  module  in  the  system  responds  to  this  event 

2  The  notion  of  a  dependency  relation  is  easily  extended  to  the  entire  system. 


deterministic  reactive  module  stopwatch  { 

type  definitions 

DS_type  =  {frozen,  active}; 

TS_type  =  {stopped,  running}; 

Time  =  integer  in  [0: infinity] ; 

monitored  variables 

boolean  HS,  start_stop,  button_2; 

controlled  variables 
Time  display; 

internal  variables 

Time  elapsed_time ; 

TS_type  Timer _Status ; 

DS_type  Display_Status ; 

assumptions 


guarantees 


definitions  /*  Definitions  of  all  internal  and  controlled  variables  */ 
}  //  end  module  stopwatch 


Fig.  2.  The  skeleton  of  the  SOL  module  for  stopwatch. 


by  updating  all  its  dependent  (i.e. ,  internal  and  controlled)  variables  and/or 
invoking  methods.  All  updates  and  method  calls  of  the  system  are  assumed  to  be 
synchronous  (similar  to  the  Synchrony  Hypothesis  of  languages  such  as  Esterel, 
LUSTRE,  etc.  [11])  -  it  is  assumed  that  the  response  to  a  triggering  event  is 
completed  in  one  step,  i.e,  all  updates  to  dependent  variables  and  all  method 
calls  are  performed  by  the  modules  of  the  system  before  the  next  triggering 
event.  Moreover,  all  updates  are  performed  in  an  order  that  is  consistent  with 
the  partial  order  imposed  by  the  dependency  graph.  For  the  stopwatch  example, 
module  stopwatch  responds  to  a  triggering  event3  by  updating  its  dependent 
variables  in  compliance  with  the  dependency  order  (see  Figure  1).  One  possible 
order  is  Timer_Status  — >  elapsed_time  — >  display  — >  Display  .Status. 

The  skeleton  of  the  SOL  module  for  stopwatch  is  shown  in  Figure  2.  Note 
that  C-style  comments  are  supported  -  all  text  between  an  opening  “/*”  and 
closing  “*/”  is  ignored.  Alternately,  comments  may  begin  with  “//”  and  termi¬ 
nate  by  the  end  of  the  line.  Comments  may  be  nested.  The  module  definition 

Since  stopwatch  is  reactive,  all  triggering  events  are  external  to  the  module. 


3 


defn  :  lvalue  "  =  "  expr  |  lvalue  "="  "initially"  expr  "then"  expr  " 

lvalue  :  ID  \  ID"["  index  "1"  |  "  ["  lvalue  lvalue]*  "]" 

expr  :  value  |  " ! "  expr  \  expr  booLbinop  expr  \  if-expr  |  case-expr  |  basic-event 

cond-event  \  "PREV"  "("  expr")"  \  expr  reLbinop  expr  \  "+"  expr  \  expr 

expr  arith-binop  expr  \  ID  "  ["  index  "]"  |  ID  "("  [  exprJ]?  ")"  |  "  ["  exprJ  "]  " 


"("  expr  ")" 

if-expr  : 

"if" 

"{"  [  "  []  "  expr"->"  expr  ]+ 

[  "otherwise"  expr  ]? 

case-expr  : 

"case"  expr  [  "  []  "  value  [  " 

[  "otherwise"  expr]? 

value  ]*  expr  ]+ 

cond-event  : 

basic- 

event  "when"  expr 

basic-event  : 

"@ID 

"  [  "("  exprJ  ")"  ]?  |  "@T"  " 

("  expr  ")"  |  "OF"  "(" 

expr  " ) "  | 

exprJ  : 

expr  [ 

"  , "  expr  ]* 

value  : 

index 

|  REAL  |  STRING  \ 

"true"  |  "false"  | 

"infinity" 

index  : 

scalar-value  |  scalar-value  "  :  "  scalar-value 

scalar-value  : 

ID  | 

INT 

booLbinop  : 

"&" 

|  "&&"  |  " 1 "  |  "II"  | 

"=>"  |  "<=>" 

reLbinop  : 

II  ^  II 

|  II  ^  _  II  |  II  —  —  II  |  II  |  —  II  | 

II  ^  It  |  IIN>=II 

arith-binop  : 

II  _j_  II 

|  ll_H  |  M*M  |  ll/M 

Legend: 

|  Choice 
]?  Optional 
]*  Zero  or  more 
1+  One  or  more 


Fig.  3.  The  syntax  of  SOL  definitions. 


comprises  a  sequence  of  sections,  all  of  them  optional,  each  beginning  with  one 
or  more  keywords.  User-defined  types  are  defined  in  the  type  definitions  sec¬ 
tion.  Each  entry  in  this  section  consists  of  an  identifier  for  the  type,  followed  by 
its  definition,  which  may  be  in  terms  of  the  built-in  types,  their  subranges,  or 
enumerated  types. 


4.3  SOL  Definitions 

The  definitions  section  is  at  the  heart  of  a  SOL  module.  The  syntax  of  SOL 
definitions  is  shown  in  Figure  3.  This  section  determines  how  each  internal  and 
controlled  variable  of  the  module  is  updated  in  response  to  events  (i.e.,  method 
calls  or  state  changes)  generated  either  internally  or  by  the  module’s  environ¬ 
ment.  Figure  4  includes  all  definitions  of  the  module  stopwatch. 


assumptions 

NAT  =  initially  (!HS  &  !button_2  &  !start_stop)  then 

(!HS  &  !button_2)  I  ( ! HS  &  !start_stop)  I  (!button_2  &  ! start_stop) ; 


guarantees 

Button2_to_frozen  =  initially  true  then 

@T(button_2)  when  (Timer_Status  ==  running  and  Display_Status  ==  active) 
=>  Display_Status  ==  frozen; 

Button2_to_not_frozen  =  initially  true  then 

@T(button_2)  when  Display_Status  ==  frozen  =>  Display_Status  ==  active; 


definitions 

Display_Status  =  initially  active  then 
if  { 

[]  @T(button_2)  when  (Display_Status  ==  frozen)  ->  active 

[]  @T(button_2)  when  (Display_Status  ==  active  & 

Timer_Status  ==  running)  ->  frozen 
otherwise  ->  PREV(Display_Status) 

}; 


Timer_Status  =  initially  stopped  then 
if  { 

[]  @T (start_stop)  when  (Timer_Status  ==  stopped)  ->  running 
[]  @T (start_stop)  when  (Timer_Status  ==  running)  ->  stopped 
otherwise  ->  PREV(Timer_Status) 

}; 


display  =  initially  0  then 
if  { 

[] @C (elapsed_time)  when  (Display_Status  ==  active)  ->  elapsed_time 
otherwise  ->  PREV (display) 

}; 


elapsed_time  =  initially  0  then 
if  { 

[]  @T  (button_2)  when  (Timer_Status  ==  stopped  & 

Display_Status  ==  active)  ->  0 

[]@T(HS)  when  (Timer_Status  ==  running)  ->  PREV(elapsed_time)  +  1 
otherwise  ->  PREV(elapsed_time) 

}; 


Fig.  4.  Sections  assumptions,  guarantees,  and  definitions  of  stopwatch. 


A  variable  definition  is  either  a  one-state  or  a  two-state  definition.  A  one- 
state  definition,  of  the  form  x  =  expr  (where  expr  is  an  expression),  defines 
the  value  of  variable  x  in  terms  of  the  values  of  other  variables  in  the  same 
state.  A  two-state  variable  definition,  of  the  form  x  =  initially  init  then  expr 
(where  expr  is  a  two-state  expression),  requires  the  initial  value  of  x  to  equal 
expression  init ;  the  value  of  x  in  each  subsequent  state  is  determined  in  terms 
of  the  values  of  variables  in  that  state  as  well  as  the  previous  state  (specified 
using  operator  PREV  or  by  a  when  clause).  A  conditional  expression ,  consisting  of 
a  sequence  of  branches  “  []  guard  — )•  expression” ,  is  introduced  by  the  keyword 
“if”  and  enclosed  in  braces  ("{"  and  "}").  A  guard  is  a  boolean  expression.  The 
semantics  of  the  conditional  expression  if  {  \\gi  — )•  exp^  \\g2  — >-  expr2  ...  }  is 
defined  along  the  lines  of  Dijkstra’s  guarded  commands  [9]  -  in  a  given  state, 
its  value  is  equivalent  to  expression  expr,:  whose  associated  guard  g\  is  true.  If 
more  than  one  guard  is  true,  the  expression  is  nondeterministic.  It  is  an  error  if 
none  of  the  guards  evaluates  to  true,  and  execution  aborts.  The  case  expression 
case  expr  {  []iq  — >  exprx  []ro  — >  expr2  ...  }  is  equivalent  to  the  conditional 
expression  if  {  [](e;r pr  ==  iq)  — >  exprj  [](expr  ==  v2)  —>  expr2  . . .  }.  The  con¬ 
ditional  expression  and  the  case  expression  may  optionally  have  an  otherwise 
clause  with  the  obvious  meaning.  In  this  paper,  we  shall  not  elaborate  on  the 
tuple  and  array  constructs  of  SOL  (see  [22]  for  details). 

The  definitions  of  module  stopwatch,  shown  in  Figure  4,  have  a  direct  corre¬ 
spondence  to  phrases  in  the  prose  specification.  For  example,  statements 

[]  @T(start_stop)  when  (Timer .Status  ==  stopped)  ->  running 

[]  @T(start_stop)  when  (Timer .Status  ==  running)  ->  stopped 

correspond  to  the  phrase  “. . .  [the]  button  start-stop  alternately  puts  the  stop¬ 
watch  in  ‘running’  and  ‘stopped’  states”. 


4.4  Assumptions  and  Guarantees 

The  assumptions  of  a  module,  which  are  typically  assumptions  about  the  en¬ 
vironment  of  the  subsystem  being  defined,  are  included  in  the  assumptions 
section.  It  is  up  to  the  user  to  make  sure  that  the  set  of  assumptions  is  not 
inconsistent,  i.e.,  a  logical  contradiction.  Users  specify  the  module  invariants  in 
the  guarantees  section,  which  is  automatically  verified  by  a  tool  such  as  Salsa. 
The  syntax  for  specifying  module  assumptions  and  guarantees  is  identical  to 
that  of  module  definitions,  in  other  words,  we  have  the  expressiveness  of  the 
full  language  in  these  clauses.  This  does  not  have  a  detrimental  effect  on  the 
proof  tools,  since  most  commonly  encountered  theorems  about  SOL  programs 
are  decidable. 

The  assumptions  and  guarantees  for  the  stopwatch  example  are  shown  in 
Figure  4.  The  assumption  NAT  specifies  that  all  the  monitored  variables  of  the 
module  are  false  in  the  initial  state  and  that  in  all  subsequent  states  at  most 
one  of  the  monitored  variables  is  true.  The  guarantees  are  a  formalization  of 
the  sentence  “If  button_2  is  pressed  when  the  stopwatch  is  running  and  active, 


it  becomes  frozen;  when  it  is  pressed  when  the  stopwatch  is  frozen,  it  becomes 
active.”  from  [11]. 


5  Formal  Verification 

Salsa  is  a  tool  for  the  verification  of  synchronous  reactive  systems.  The  verifica¬ 
tion  performed  by  Salsa  is  invariant  checking  in  addition  to  consistency  checking 
[16]  which  flags  undesirable  instances  of  nondeterminism  and  missing  cases  in  a 
module.  Consider  the  following  code  fragment  of  stopwatch: 

elapsed_time  =  initially  0  then 
if  { 

[]  @T  (button_2)  when  (Timer_Status  ==  stopped  ft 

Display_Status  ==  active)  ->  0 

□  @T(HS)  when  (Timer_Status  ==  running)  ->  PREV(elapsed.time)  +  1 
otherwise  ->  PREV(elapsed_time) 

}; 


Checking  for  disjointness  is  to  determine  whether  events 

ei  =  @T(button_2)  when  (Timer .Status  ==  stopped  & 

Display  .Status  ==  active) 
e2  =  @T(HS)  when  (Timer .Status  ==  running) 

of  the  two  guards  can  both  occur  in  any  reachable  system  state.  If  so,  the 
module  is  said  to  have  a  disjointness  error  (since  the  module  is  declared  as 
deterministic). 

The  above  problem  may  be  reduced  to  checking  whether  the  expression 
“initially  true  then  -i(ei  Ae2)”  is  an  invariant  of  stopwatch.  All  the  disjoint¬ 
ness  verification  conditions  of  stopwatch  were  verified  automatically  by  Salsa  in 
about  a  tenth  of  a  second.  Along  similar  lines,  one  can  prove  that  the  properties 
in  the  guarantees  section  are  invariants.  These  too  were  verified  automatically 
by  Salsa  in  under  a  second.  If  an  invariant  is  not  provable,  Salsa  returns  a  coun¬ 
terexample.  However,  one  should  keep  in  mind  that  due  to  the  incompleteness 
of  induction,  users  must  validate  that  the  returned  counterexample  is  reachable. 
By  examining  the  counterexamples,  users  will  be  able  to  either  determine  that 
there  is  a  problem  or  will  have  to  prove  additional  invariants  as  lemmas  in  order 
to  prove  the  original  invariant. 

6  Enforcement  Automata 

In  this  section,  we  shall  examine  how  enforceable  safety  and  security  policies  [23] 
are  expressed  in  SOL  as  enforcement  automata  (also  known  as  security  agents 
[3]).  The  enforcement  mechanism  of  SOL  works  by  terminating  all  executions  of 
a  program  for  which  the  policy  being  enforced  no  longer  holds.  For  reasons  of 
readability  and  maintainability,  we  prefer  to  use  explicit  automata  for  enforcing 


deterministic  reactive  module  safestack(integer  max_depth)  { 
interfaces 

void  push(integer  x) ; 

void  pop  ()  ; 

integer  topO; 

internal  variables 

{empty,  nonempty}  status; 

integer  in  [0:max_depth]  depth; 

guarantees 

INV1  =  (status  ==  empty)  <=>  (depth  ==  0) ; 
definitions 

[status,  depth]  =  initially  [empty,  0]  then 
case  PREV(status)  { 

[]  empty  -> 
if  { 

[]  @push  ->  [nonempty,  PREV (depth)  +  1] 

//  other  operations  illegal! 

} 

[]  nonempty  -> 
if  { 

[]  Stop  ->  [PREV(status)  ,  PREV(depth)] 

//  Spop  when  (depth  ==  0)  impossible!  (by  INV1) 

[]  Spop  when  (depth  >  1)  ->  [nonempty,  PREV  (depth)  -  1] 

[]  Spop  when  (depth  ==  1)  ->  [empty,  0] 

[]  Spush  when  (depth  <  max_depth)  ->  [nonempty,  PREV (depth)  +  1] 
//  ©push  when  (depth  ==  max_depth)  illegal! 

} 

};  //  end  case 
}  //  end  module  safestack 


Fig.  5.  A  SOL  module  providing  a  safe  interface  to  stack. 

safety  properties  and  security  policies,  although  any  language  that  allows  ref¬ 
erences  to  previous  values  of  variables  may  suffice.  Unlike  assertions,  where  no 
additional  state  is  maintained,  SOL  enforcement  automata  may  include  addi¬ 
tional  variables  that  are  updated  during  the  transitions  of  the  automata. 

6.1  Safety  Automata 

We  examine  how  SOL  automata  are  used  to  enforce  safety  policies.  The  example 
we  shall  use  is  a  stack,  which  has  the  associated  methods  push,  pop,  and  top. 
Informally,  push(x)  pushes  the  value  of  integer  variable  x  on  the  stack  and  pop() 
pops  the  topmost  value  off  the  stack.  The  method  top()  returns  the  current  value 
at  the  top  of  the  stack.  The  stack  can  accommodate  at  most  max_depth  items. 
The  safety  policies  we  wish  to  enforce  are:  (i)  No  more  than  max_depth  items 
are  pushed  on  the  stack,  (ii)  Invocations  of  methods  top  and  pop  are  disallowed 
on  an  empty  stack. 


/depth  -  0  @ push / depth  =  depth  + 


f  ' 

empty 

nonempty 

|  (depth  ==  0) 

(depth  >  0) 

@pop  when  (depth  = 

=  1)  /  depth  =  0 

@push  when  (depth  <  max_depth)  / 
depth  =  depth  +  1 


@pop  when  (depth  >  1)  / 
depth  =  depth  -  1 


Fig.  6.  Visual  representation  of  safestack. 


The  classical  way  of  specifying  the  correct  use  of  a  stack  would  be  to  write 
a  so-called  class  invariant,  often  specified  as  predicates  on  the  “old”  and  “new” 
values  of  program  variables.  Languages  such  as  Eiffel  [19]  with  explicit  support 
for  Design  by  Contract  [18]  include  constructs  for  specifying  and  checking  such 
invariants.  However,  presently  popular  object-oriented  programming  languages 
lack  such  mechanisms,  and  therefore  treat  class  invariants  mostly  as  comments, 
and  provide  no  tool  support  to  analyze  them.  A  unique  feature  of  SOL  is  the 
ability  to  perform  such  checks  on  existing  implementations  in  a  language-neutral 
manner.  Figure  5  shows  a  SOL  module  safestack  which  enforces  these  safety 
policies  on  all  SOL  modules  which  use  the  stack  object  (implemented  in  the 
embedding  language).  Figure  6  is  the  module  safestack  rendered  in  the  visual 
syntax  of  SOL.  Note  that  by  deliberately  omitting  the  otherwise  clauses  in  the 
if  statements,  we  abort  the  execution  of  the  program  when  none  of  the  guards 
is  true.  If  this  is  too  drastic,  corrective  action  may  be  specified  in  an  otherwise 
clause;  for  example,  to  ignore  all  push  actions  when  the  stack  is  full. 


6.2  Security  Automata 

We  use  the  example  from  [23]  to  illustrate  how  we  may  implement  a  security 
policy  that  allows  a  software  agent  to  send  data  to  remote  hosts  (using  method 
send)  as  well  as  read  local  files  (using  method  f  ile_read).  However,  invocations 
of  send  subsequent  to  f  ile_read  are  disallowed.  It  is  difficult,  if  not  impossible, 
to  configure  current  systems  to  implement  such  a  policy.  For  example,  it  cannot 
be  implemented  in  the  “sandbox”  model  of  Java  [10]  in  which  one  may  either 
always  or  never  allow  access  to  a  system  resource.  As  shown  in  Figure  7,  this 
policy  is  easily  implemented  in  SOL. 


7  Future  Work 

We  plan  to  continue  the  development  of  design  and  analysis  tools  for  SOL  pro¬ 
grams,  which  will  include  a  graphical  user  interface  for  a  visual  (Statecharts¬ 
like)  representation  for  SOL,  and  verification  tools  such  as  automatic  invariant 
generators  and  checkers,  theorem  provers,  and  model  checkers.  A  Java™  in¬ 
terpreter  for  SOL,  SOLi,  is  currently  under  development.  We  plan  to  support 
other  language  embeddings  such  as  C#  and  C++.  Planned  extensions  to  the 


deterministic  reactive  module  SecureRead  { 


interfaces 

string  f ile_read(string  filename,  int  position,  int  size); 
void  send(string  address,  string  data); 

internal  variables 

{no_reads,  read_perf ormed}  status; 

definitions 

status  =  initially  no_reads  then 
case  PREV(status)  { 

[]  no_reads  -> 
if  { 

[]  @send  ->  PREV(status) 

[]  <§file_read  ->  read_performed 

} 

[]  read_performed  -> 
if  { 

[]  @file_read  ->  read_performed 
//  Osend  illegal! 

> 

};  //  end  case 
}  //  end  module  SecureRead 

Fig.  7.  A  SOL  module  that  implements  safe  access  to  local  files. 


interpreter  includes  support  for  security  (such  as  authentication,  authorization, 
non-repudiation,  and  confidentiality)  and  decentralized  distributed  execution,  for 
which  we  need  to  address  associated  problems  such  as  fault-tolerance,  load  bal¬ 
ancing,  self-stabilization,  and  survivability.  Another  area  of  research  is  to  provide 
support  for  implementing  hard  real-time  systems. 
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